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DETAILED ACTION 



This Office Action is responsive to Applicants amendment and request for 
continued examination (Paper No. 9) of application 09/183,335 filed October 30, 1998. 
The amendment filed July 30, 2002 amended several claims but canceled none of 
them. Accordingly Claims 1-29 are presented for examination on their merits. 

Claim Rejections - 35 USC § 101 

1. 35 U.S.C. 101 reads as follows: 

Whoever invents or discovers any new and useful process, machine, manufacture, or composition of 
matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the 
conditions and requirements of this title. 

2. Claims 1 and 23 and all claims dependent upon them both are rejected under 
U.S.C. 101 because the claims have no connection to the technological arts. While the 
term "database system" may infer that it was part of a computer system, the database 
could also be a manual system of cards or tabs or some other type of manual system. 
To overcome this rejection, the Examiner suggests that the Applicant amend the claims 
to better clarify that the method is using a database within the technological arts, such 
as modifying "database" with the word "computer", in both the preamble and the body of 
the claims. 

Response To Arguments 

3. Applicants amendments filed on July 30, 2002 have been fully considered, but 
the Applicants arguments are not found to be persuasive. Accordingly the prior rejection 
remains in effect. 
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Art Unit: 3628 

DETAILED ACTION 

4. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 

obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed 
or described as set forth in section 102 of this title, if the differences between the 
subject matter sought to be patented and the prior art are such that the subject 
matter as a whole would have been obvious at the time the invention was made 
to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was 
made. 



Rejection, 35 U.S.C. 103(a) 

Claims 1-5, 17-20, and 22-29 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Gottesman et al (US 6,049,782 A) (hereinafter "Gottesman") 
and Petroutsos (Mastering Visual Basic 5), in view of each other as noted below. 

As to Claim 1 Gottesman discloses directly or inherently (see at least cols 1-14, 
but particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, and col 8, lines 1- 
16) all of the steps in amended claim 1 , both as an inventive concept and as computer 
program functions and steps to be performed, either implicitly or explicitly. He teaches 
the creation and use of price tables and tier/pricing (product) rules for both products 
and sub-products linked to financial transactions, and rules linked to price tables, 
identifying the correct rule for the transaction, and pricing the transaction according to 
the tier/pricing (product) rules. All of the claimed steps are also inherent in what 
Gottesman teaches. But he does not specifically teach the detailed programmatic steps 
for these software logic functions. 

Petroutsos teaches (see his book in general, but particularly Chapter 3 at least 
the sections "Arrays" through "Arrays of Arrays", and "If.. Then. ..End", and Chapter 1 1 
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at least the sections "Databases and Database Management Systems" through "The 
Data Control's Properties"), by example of one of several computer programming 
languages then available, how relatively logical, simple, and obvious it would have been 
for one skilled in the art at the time of the invention to create all the programming steps 
necessary to translate an inventive concept, like Gottesman's described computer logic 
functions to be performed, into a working computer software program. For such skilled 
programmers it would have been obvious in a financial transaction system containing 
price tables and product (component) rules for multiple products (components) and 
multiple prices to develop the computer logic and the means for the entering of specific 
pricing and other calculations required in the tables and to employ specific names, 
identifiers, and references for the pricing and product (component) databases (tables) 
and their data fields, together with the programmatic means to both create all of the 
logic and tables and to link and associate them all together for the purpose and function 
intended to be performed, including display only information. It is inherent in such 
programs to always have both mandatory and optional attributes in their tables and 
rules, and to assign status and a name to each of them. For example a table or field 
identifier is mandatory in order for the program to function properly, yet the number and 
type of fields and the individual rule descriptions and logic are discretionary. It would 
also be obvious to allow for the temporary disuse of one or more of those rules as an 
optional attribute, for a variety of operational reasons: possible temporary 
discontinuance of the product as one example, or a change in the attributes of the 
product itself as another reason. In view of Gottesmans' teaching, it would have been 
obvious to one skilled in the art at the time of the invention to integrate Gottesmans' 
invention with the teachings of Petroutsos because the combination of the two would 
have provided a completed, improved, and operational financial transaction system that 
could have been used by financial service companies. Likewise, in light of Petroutsos' 
teaching, it would have been obvious to one skilled in the art at the time of the invention 
to integrate the teachings of Petroutsos with those of Gottesman for the same reason. 
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As to Claim 2 Gottesman discloses (see at least cols 1-14, but particularly col 
4. lines 42-67, col 5, lines 1-57, col 7, lines 48-67. col 8, lines 1-16, and col 13) all of the 
steps in amended claim 2, both as an inventive concept and as computer program 
functions and steps to be performed, either implicitly or explicitly. He inherently teaches 
the use of price tables and tier/pricing (product) rules for both products and sub- 
products linked to financial transactions, and rules linked to price tables, identifying the 
correct rule for the transaction, and pricing the transaction according to the tier/pricing 
(product) rules, all towards the logical end purpose of utilizing all of those steps for a 
billing method. See response to claim 1. 

As to Claim 3 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, and 
col 13) "The method of Claim 1... display only information.", both as an inventive 
concept and as computer program functions to be performed with as many other pieces 
of identifying and descriptive information as would have been needed to effectively 
operate the system. It would have been obvious to one skilled in the art at the time of 
the invention to have utilized a display only option, as not all computer screens require 
either text or a response, and to have included all the steps described in this claim. See 
response to claim 1 . 

As to Claim 4 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, and col 8, lines 1-16) 
"The method of Claim 1....a price table.". , both as an inventive concept and as 
computer program functions to be performed. See response to claimi . 

As to Claim 5 Gottesman discloses (see at least cols 1-14, but particularly col 
4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, and col 8, lines 1-16) "The method of 
Claim 1 ....a pricing method." , both as an inventive concept and as computer program 
functions to be performed. See response to claim 1. 
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As to Claim 17 Gottesman discloses (see at least cols 1-14, but particularly col 
4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, and col 8, lines 1-16) "The method of 
Claim 1...for said product rule". , both as an inventive concept and as computer 
program functions to be performed. See response to claim 1 . 

As to Claim 18 Gottesman discloses (see at least cols 1-14, but particularly col 
4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, and col 8, lines 1-16) "The method of 
Claim 1... .product rules to a database." , both as an inventive concept and as computer 
program functions to be performed. See response to claim 1 . 

As to Claim 19 Gottesman discloses (see at least cols 1-14, but particularly col 
4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, and col 8, lines 1-16) "The method of 
Claim 1 ....a default product rule.", both as an inventive concept and as computer 
program functions to be performed. See response to claim 1 . 

As to Claim 20 Gottesman discloses (see at least cols 1-14, but particularly col 
4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, and col 8, lines 1-16) "The method of 
Claim 1.... price table contains prices.", both as an inventive concept and as computer 
program functions to be performed. See response to claim 1 . 

As to Claim 22 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 
10, lines 55-67, and cols 11-13) "The method of Claim 1, wherein said price table 
contains negative values", both as an inventive concept and as means for computer 
program functions to be performed. 

OFFICIAL NOTICE is taken that it would have been obvious for pricing tables to 
have contained negative values for the purpose of zeroing out a prior price entry by 
either multiplying it by a negative 1 or have the actual price be a negative number to be 
added to the prior entry in order to zero it out, to make the price table function properly. 
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In view of Gottesmans* teaching, it would have been obvious to one skilled in the art at 
the time of the invention to integrate Gottesmans' invention and OFFICIAL NOTICE with 
the teachings of Petroutsos because the combination of the three would have provided 
a completed, improved, and operational financial transaction system that could have 
been used by financial service companies. Likewise, in light of Petroutsos' teaching, it 
would have been obvious to one skilled in the art at the time of the invention to integrate 
the teachings of Petroutsos and OFFICIAL NOTICE with those of Gottesman for the 
same reason. 

As to Claim 23 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 
10, lines 55-67, and cols 11-13) "A data processing system.... said product rule and said 
price table.", both as an inventive concept and as means for computer program 
functions to be performed, but he does not specifically teach the detailed programmatic 
steps for these software functions, such as "mandatory and optional" attributes as such. 
Petroutsos teaches (see his book in general, but particularly Chapter 3 at least the 
sections "Arrays" through "Arrays of Arrays", and "If. Then. ..End", and Chapter 11 at 
least the sections "Databases and Database Management Systems" through "The Data 
Control's Properties'*), by example of one of several computer programming languages 
then available, how relatively logical, simple, and obvious it would have been for one 
skilled in the art at the time of the invention to create the programming steps necessary 
to translate an inventive concept, like Gottesman's described computer functions to be 
performed, into a working computer software program. For such skilled programmers it 
would have been obvious in a financial transaction system containing price tables and 
product (component) rules for multiple products (components) and multiple prices to 
develop the computer logic and the means for the pricing and other calculations 
required and to employ specific names, identifiers, and references for the pricing and 
product (component) databases (tables) and their data fields, together with the 
programmatic means to both create all of the logic and tables and to link them all 
together for the purpose and function intended to be performed. It is inherent in such 
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programs to always have both mandatory and optional attributes in their tables and 
rules. For example a table or field identifier is mandatory in order for the program to 
function properly, yet the number and type of fields and the individual rule descriptions 
and logic are discretionary. It would also be obvious to allow for the temporary disuse of 
one or more of those rules as an optional attribute, for a variety of operational reasons: 
possible temporary discontinuance of the product as one example, or a change in the 
attributes of the product itself as another reason. In view of Gottesmans' teaching, it 
would have been obvious to one skilled in the art at the time of the invention to integrate 
Gottesmans' invention with the teachings of Petroutsos because the combination of the 
two would have provided a completed, improved, and operational financial transaction 
system that could have been used by financial service companies. Likewise, in light of 
Petroutsos' teaching, it would have been obvious to one skilled in the art at the time of 
the invention to integrate the teachings of Petroutsos with those of Gottesman for the 
same reason. See response to claim 1 . 

As to Claim 24 Gottesman discloses (see at least cols 1-14, but particularly col 
4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 10, lines 55-67, 
and cols 11-13) "The data processing system.... means for billing.", both as an inventive 
concept and as means for computer program functions to be performed. See response 
to claim 1 . 

As to Claim 25 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 
10, lines 55-67, and cols 11-13) "The data processing system.... display only 
information.", both as an inventive concept and as means for computer program 
functions to be performed. See response to claims 1 and 3. 

As to Claim 26 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 
10, lines 55-67, and cols 11-13) "The data processing system of Claim 23.... said 



Application/Control Number: 09/183,335 
Art Unit: 3628 



Page 9 



mandatory attributes.", both as an inventive concept and as means for computer 
program functions to be performed. See response to claim 1 . 

As to Claim 27 Gottesman discloses (see at least cols 1-14, but particularly col 
4, lines 42-67. col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16. col 10, lines 55-67, 
and cols 11-13) "The data processing system of Claim 26. ...said identifier.", both as an 
inventive concept and as means for computer program functions to be performed. See 
response to claim 1 . 

As to Claim 28 Gottesman discloses (see at least cols 1-14. but particularly col 

4, lines 42-67, col 5, lines 1-57, col 7. lines 48-67, and col 8, lines 1-16) "The data 
processing system.... rules to a database." , both as an inventive concept and as 
computer program functions to be performed. See response to claim 1. 

As to Claim 29 Gottesman inherently discloses (see at least cols 1-14. but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 
10, lines 55-67, and cols 11-13) "The data processing system of Claim 23. ...a default 
product rule.", both as an inventive concept and as means for computer program 
functions to be performed. Whenever there are several choices of actions to be applied 
to a table of rules and one or more of the rules has no special action specified in the 
original design of the table, then it is obvious to one skilled in the art at the time of the 
invention to have provided the means for a default action to that rule, and consequently 
provide for that eventuality in the design of the program logic. See response to claim 1 . 

Rejection, 35 U.S.C. 103(a) 

5. Claims 6-16 and 21 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Gottesman et a! (US 6,049,782 A) (hereinafter "Gottesman") and Petroutsos 
(Mastering Visual Basic 5), further in view of Carter (US 5,878,400) as noted below. 
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As to Claim 6 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 
10, lines 55-67, and cols 11-13) "The method of Claim 5.... is flat fee.", both as an 
inventive concept for pricing as commonly used in financial transactions and as means 
for computer pricing program functions to be performed, but he does not teach the 
many specific variations of pricing , all of which are old and well known, nor the detailed 
programmatic steps for these software functions. Petroutsos teaches (see his book in 
general, but particularly Chapter 3 at least the sections "Arrays" through "Arrays of 
Arrays", and "If.. Then. ..End", and Chapter 1 1 at least the sections "Databases and 
Database Management Systems" through "The Data Control's Properties"), by example 
of one of several computer programming languages then available, how relatively 
logical, simple, and obvious it would have been for one skilled in the art at the time of 
the invention to create the programming steps necessary to translate an inventive 
concept, like Gottesman's described computer functions to be performed, into a working 
computer software program. Carter teaches (see at least Figure 7) approximately 25 
different types of commonly used pricing types, which are only a partial listing of the 
many common pricing types, some of which have been used for the past several 
millenia. For such skilled programmers it would have been obvious in a financial 
transaction system containing price tables and product (component) rules for multiple 
products (components) and multiple prices and pricing types to develop the computer 
logic for the many commonly known and used different types of pricing methods 
required for the many products involved and the means for the pricing and other 
calculations required and to employ specific names, identifiers, and references for the 
pricing and product (component) databases (tables) and their data fields, together with 
the programmatic means to both create all of the logic and tables and to link them all 
together for the purpose and function intended to be performed, including specifically 
flat fee pricing. OFFICIAL NOTICE is taken that one of the oldest and best known 
pricing types is the flat fee type, which has long been commonly used for services of all 
types, such as Doctors, gardeners, hairdressers, and bank services, etc., and that it 



Application/Control Number: 09/1 83,335 Page 1 1 

Art Unit: 3628 

would have been obvious to modify the teachings of Carter with this OFFICIAL 
NOTICE. In view of Gottesmans' teaching, it would have been obvious to one skilled in 
the art at the time of the invention to employ the teachings of Gottesman to the 
teachings of Petroutsos as modified by Carter because the combination of the three 
would have provided a completed, improved, and operational financial transaction 
system that could have been used by financial service companies, complete with a wide 
variety of pricing types. Likewise, in light of Carter's teaching and that of OFFICIAL 
NOTICE, it would have been obvious to one skilled in the art at the time of the invention 
to integrate the teachings of Carter and OFFICIAL NOTICE and Petroutsos with those 
of Gottesman for the same reason. 

As to Claim 7 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 
10, lines 55-67, and cols 11-13) "The method of Claim 5.... is unit price.", both as an 
inventive concept for pricing as commonly used in financial transactions and as means 
for computer pricing program functions to be performed. 

OFFICIAL NOTICE is taken that one of the oldest and best known pricing types 
is the unit price type, which has long been commonly used for goods of all types, such 
as groceries, office supplies, clothes, and bank services, etc., and that it would have 
been obvious to modify the teachings of Carter with this OFFICIAL NOTICE. In view of 
Gottesmans' teaching, it would have been obvious to one skilled in the art at the time of 
the invention to employ the teachings of Gottesman to the teachings of Carter because 
the combination of the two would have provided a completed, improved, and operational 
financial transaction system that could have been used by financial service companies, 
complete with a wide variety of pricing types. Likewise, in light of Carter's teaching and 
that of OFFICIAL NOTICE, it would have been obvious to one skilled in the art at the 
time of the invention to integrate the teachings of Carter and OFFICIAL NOTICE with 
those of Gottesman for the same reason. See responses to claims 1 and 6. 
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As to Claim 8 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5. lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 
10, lines 55-67. and cols 11-13) "The method of Claim 5.... is unit cost.", both as an 
inventive concept for pricing as commonly used in financial transactions and as means 
for computer pricing program functions to be performed. 

OFFICIAL NOTICE is taken that one of the oldest and best known pricing types 
is the unit cost type, which has long been commonly used for goods and services in 
special circumstances, such as for sales of goods or services which were in addition to 
other sales being made at the same time to the same customer or as an special 
incentive or a promotional price, and that it would have been obvious to modify the 
teachings of Carter with this OFFICIAL NOTICE. In view of Gottesmans' teaching, it 
would have been obvious to one skilled in the art at the time of the invention to employ 
the teachings of Gottesman to the teachings of Carter because the combination of the 
two would have provided a completed, improved, and operational financial transaction 
system that could have been used by financial service companies, complete with a wide 
variety of pricing types. Likewise, in light of Carter's teaching and that of OFFICIAL 
NOTICE, it would have been obvious to one skilled in the art at the time of the invention 
to integrate the teachings of Carter and OFFICIAL NOTICE with those of Gottesman for 
the same reason. See responses to claims 1 and 6, 

As to Claim 9 Gottesman inherently discloses (see at least cols 1-14. but 
particularly col 4, lines 42-67. col 5. lines 1-57, col 7, lines 48-67. col 8. lines 1-16, col 
10, lines 55-67, and cols 1 1-13) "The method of Claim 5. ...is volume discount.", both as 
an inventive concept for pricing as commonly used in financial transactions and as 
means for computer pricing program functions to be performed, but he does not teach 
the many specific variations of pricing , all of which are old and well known, nor the 
detailed programmatic steps for these software functions. Petroutsos teaches (see his 
book in general, but particularly Chapter 3 at least the sections "Arrays" through "Arrays 
of Arrays", and "If.. Then. ..End", and Chapter 11 at least the sections "Databases and 
Database Management Systems" through "The Data Contrors Properties"), by example 
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of one of several computer programming languages then available, how relatively 
logical, simple, and obvious it would have been for one skilled in the art at the time of 
the invention to create the programming steps necessary to translate an inventive 
concept, like Gottesman's described computer functions to be performed, into a working 
computer software program. Carter teaches (see at least Figure 7) approximately 25 
different types of commonly used pricing types, including volume discount, which are 
only a partial listing of the many common pricing types, some of which have been used 
for the past several millenia. For such skilled programmers it would have been obvious 
in a financial transaction system containing price tables and product (component) rules 
for multiple products (components) and multiple prices and pricing types to develop the 
computer logic for the many commonly known and used different types of pricing 
methods required for the many products involved and the means for the pricing and 
other calculations required and to employ specific names, identifiers, and references for 
the pricing and product (component) databases (tables) and their data fields, together 
with the programmatic means to both create all of the logic and tables and to link them 
all together for the purpose and function intended to be performed, including specifically 
volume discount pricing. In view of Gottesmans' teaching, it would have been obvious 
to one skilled in the art at the time of the invention to employ the teachings of 
Gottesman to the teachings of Petroutsos as modified by Carter because the 
combination of the three would have provided a completed, improved, and operational 
financial transaction system that could have been used by financial service companies, 
complete with a wide variety of pricing types. Likewise, in light of Carter's teaching it 
would have been obvious to one skilled in the art at the time of the invention to integrate 
the teachings of Carter and Petroutsos with those of Gottesman for the same reason. 
See responses to claims 1 and 6. 

As to Claim 10 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 
10, lines 55-67, and cols 11-13) The method of Claim 5.... is tiering.", both as an 
inventive concept for pricing as commonly used in financial transactions and as means 



Application/Control Number: 09/183,335 
Art Unit: 3628 



Page 14 



for computer pricing program functions to be performed, but he does not teach the 
many specific variations of pricing , all of which are old and well known, nor the detailed 
programmatic steps for these software functions. Petroutsos teaches (see his book in 
general, but particularly Chapter 3 at least the sections "Arrays" through "Arrays of 
Arrays", and "If.. Then. ..End", and Chapter 11 at least the sections "Databases and 
Database Management Systems" through "The Data Control's Properties"), by example 
of one of several computer programming languages then available, how relatively 
logical, simple, and obvious it would have been for one skilled in the art at the time of 
the invention to create the programming steps necessary to translate an inventive 
concept, like Gottesman's described computer functions to be performed, into a working 
computer software program. Carter teaches (see at least Figure 7) approximately 25 
different types of commonly used pricing types, including tiering, which are only a partial 
listing of the many common pricing types, some of which have been used for the past 
several millenia. For such skilled programmers it would have been obvious in a 
financial transaction system containing price tables and product (component) rules for 
multiple products (components) and multiple prices and pricing types to develop the 
computer logic for the many commonly known and used different types of pricing 
methods required for the many products involved and the means for the pricing and 
other calculations required and to employ specific names, identifiers, and references for 
the pricing and product (component) databases (tables) and their data fields, together 
with the programmatic means to both create all of the logic and tables and to link them 
all together for the purpose and function intended to be performed, including specifically 
tiering pricing. In view of Gottesmans' teaching, it would have been obvious to one 
skilled in the art at the time of the invention to employ the teachings of Gottesman to the 
teachings of Petroutsos as modified by Carter because the combination of the three 
would have provided a completed, improved, and operational financial transaction 
system that could have been used by financial service companies, complete with a wide 
variety of pricing types. Likewise, in light of Carter's teaching it would have been 
obvious to one skilled in the art at the time of the invention to integrate the teachings of 
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Carter and Petroutsos with those of Gottesman for the same reason. See responses to 
claims 1 and 6. 

As to Claim 11 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 
10, lines 55-67, and cols 11-13) "The method of Claim 5.... is cost plus.", both as an 
inventive concept for pricing as commonly used in financial transactions and as means 
for computer pricing program functions to be performed, but he does not teach the 
many specific variations of pricing , all of which are old and well known, nor the detailed 
programmatic steps for these software functions. Petroutsos teaches (see his book in 
general, but particularly Chapter 3 at least the sections "Arrays" through "Arrays of 
Arrays", and "If.. .Then. ..End", and Chapter 11 at least the sections "Databases and 
Database Management Systems" through "The Data Control's Properties"), by example 
of one of several computer programming languages then available, how relatively 
logical, simple, and obvious it would have been for one skilled in the art at the time of 
the invention to create the programming steps necessary to translate an inventive 
concept, like Gottesman's described computer functions to be performed, into a working 
computer software program. Carter teaches (see at least Figure 7) approximately 25 
different types of commonly used pricing types, including cost plus, which are only a 
partial listing of the many common pricing types, some of which have been used for the 
past several millenia. For such skilled programmers it would have been obvious in a 
financial transaction system containing price tables and product (component) rules for 
multiple products (components) and multiple prices and pricing types to develop the 
computer logic for the many commonly known and used different types of pricing 
methods required for the many products involved and the means for the pricing and 
other calculations required and to employ specific names, identifiers, and references for 
the pricing and product (component) databases (tables) and their data fields, together 
with the programmatic means to both create all of the logic and tables and to link them 
all together for the purpose and function intended to be performed, including specifically 
cost plus pricing. In view of Gottesmans' teaching, it would have been obvious to one 
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skilled in the art at the tinne of the invention to employ the teachings of Gottesman to the 
teachings of Petroutsos as modified by Carter because the combination of the three 
would have provided a completed, improved, and operational financial transaction 
system that could have been used by financial service companies, complete with a wide 
variety of pricing types. Likewise, in light of Carter's teaching it would have been 
obvious to one skilled in the art at the time of the invention to integrate the teachings of 
Carter and Petroutsos with those of Gottesman for the same reason. See responses to 
claims 1 and 6. 

As to Claim 12 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 
10, lines 55-67, and cols 11-13) "The method of Claim 5.... is minimum revenue.", both 
as an inventive concept for pricing as commonly used in financial transactions and as 
means for computer pricing program functions to be performed, but he does not teach 
the many specific variations of pricing , all of which are old and well known, nor the 
detailed programmatic steps for these software functions. Petroutsos teaches (see his 
book in general, but particularly Chapter 3 at least the sections "Arrays" through "Arrays 
of Arrays", and "If.. .Then. ..End", and Chapter 11 at least the sections "Databases and 
Database Management Systems" through "The Data Control's Properties"), by example 
of one of several computer programming languages then available, how relatively 
logical, simple, and obvious it would have been for one skilled in the art at the time of 
the invention to create the programming steps necessary to translate an inventive 
concept, like Gottesman's described computer functions to be performed, into a working 
computer software program. Carter teaches (see at least Figure 7) approximately 25 
different types of commonly used pricing types, some of which are only a partial listing 
of the many common pricing types, some of which have been used for the past several 
millenia. For such skilled programmers it would have been obvious in a financial 
transaction system containing price tables and product (component) rules for multiple 
products (components) and multiple prices and pricing types to develop the computer 
logic for the many commonly known and used different types of pricing methods 
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required for the many products involved and the means for the pricing and other 
calculations required and to employ specific names, identifiers, and references for the 
pricing and product (component) databases (tables) and their data fields, together with 
the programmatic means to both create all of the logic and tables and to link them all 
together for the purpose and function intended to be performed, including specifically 
minimum revenue pricing. 

OFFICIAL NOTICE is taken that minimum revenue pricing is old and well 
known,and has long been commonly used for goods and services in special price 
calculation circumstances, such as whenever the proscribed calculation method 
had yielded only a very small nominal value that may not have included overhead 
or transactional expenses and the management position had been taken that all 
such transactions would have had at least a preset minimum revenue as its 
charged price, and that it would have been obvious to modify the teachings of 
Carter with this OFFICIAL NOTICE. In view of Gottesmans* teaching, it would 
have been obvious to one skilled in the art at the time of the invention to employ 
the teachings of Gottesman to the teachings of Petroutsos as modified by Carter 
and OFFICIAL NOTICE because the combination of the four would have 
provided a completed, improved, and operational financial transaction system 
that could have been used by financial service companies, complete with a wide 
variety of pricing types. Likewise, in light of Carter's teaching and that of 
OFFICIAL NOTICE, it would have been obvious to one skilled in the art at the 
time of the invention to integrate the teachings of Carter and OFFICIAL NOTICE 
and Petroutsos with those of Gottesman for the same reason. See responses to 
claims 1 and 6. 

As to Claim 13 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 
10, lines 55-67, and cols 11-13) "The method of Claim 5.... is maximum revenue.", both 
as an inventive concept for pricing as commonly used in financial transactions and as 
means for computer pricing program functions to be performed, but he does not teach 
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the many specific variations of pricing , all of which are old and well known, nor the 
detailed programmatic steps for these software functions. Petroutsos teaches (see his 
book in general, but particularly Chapter 3 at least the sections "Arrays" through "Arrays 
of Arrays", and "If.. Then. ..End", and Chapter 11 at least the sections "Databases and 
Database Management Systems" through "The Data Control's Properties"), by example 
of one of several computer programming languages then available, how relatively 
logical, simple, and obvious it would have been for one skilled in the art at the time of 
the invention to create the programming steps necessary to translate an inventive 
concept, like Gottesman's described computer functions to be performed, into a working 
computer software program. Carter teaches (see at least Figure 7) approximately 25 
different types of commonly used pricing types, some of which are only a partial listing 
of the many common pricing types, some of which have been used for the past several 
milenia. For such skilled programmers it would have been obvious in a financial 
transaction system containing price tables and product (component) rules for multiple 
products (components) and multiple prices and pricing types to develop the computer 
logic for the many commonly known and used different types of pricing methods 
required for the many products involved and the means for the pricing and other 
calculations required and to employ specific names, identifiers, and references for the 
pricing and product (component) databases (tables) and their data fields, together with 
the programmatic means to both create all of the logic and tables and to link them all 
together for the purpose and function intended to be performed, including specifically 
maximum revenue pricing. 

OFFICIAL NOTICE is taken that maximum revenue pricing is old and well known, 
and has long been commonly used for goods and services in special price calculation 
circumstances, such as whenever the proscribed calculation method had yielded an 
unusually high value that may not have been competitive or not have appeared 
reasonable to the customer, and the management position had been taken that all such 
transactions will have had at most a preset maximum revenue as its charged price, and 
that it would have been obvious to modify the teachings of Carter with this OFFICIAL 
NOTICE. In view of Gottesmans' teaching, it would have been obvious to one skilled in 



Application/Control Number: 09/183.335 Page 19 

Art Unit: 3628 

the art at the time of the invention to employ the teachings of Gottesman to the 
teachings of Petroutsos as modified by Carter and OFFICIAL NOTICE because the 
combination of the FOUR would have provided a completed, improved, and operational 
financial transaction system that could have been used by financial service companies, 
complete with a wide variety of pricing types. Likewise, in light of Carter's teaching and 
that of OFFICIAL NOTICE, it would have been obvious to one skilled in the art at the 
time of the invention to integrate the teachings of Carter and OFFICIAL NOTICE and 
Petroutsos with those of Gottesman for the same reason. See responses to claims 1 
and 6. 

As to Claim 14 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 
10, lines 55-67, and cols 11-13) "The method of Claim 5.... is markup of total price.", 
both as an inventive concept for pricing as commonly used in financial transactions and 
as means for computer pricing program functions to be performed, but he does not 
teach the many specific variations of pricing , all of which are old and well known, nor 
the detailed programmatic steps for these software functions. Petroutsos teaches (see 
his book in general, but particularly Chapter 3 at least the sections "Arrays" through 
"Arrays of Arrays", and "If.. .Then. ..End", and Chapter 1 1 at least the sections 
"Databases and Database Management Systems" through "The Data Control's 
Properties"), by example of one of several computer programming languages then 
available, how relatively logical, simple, and obvious it would have been for one skilled 
in the art at the time of the invention to create the programming steps necessary to 
translate an inventive concept, like Gottesman's described computer functions to be 
performed, into a working computer software program. Carter teaches (see at least 
Figure 7) approximately 25 different types of commonly used pricing types, some of 
which are only a partial listing of the many common pricing types, some of which have 
been used for the past several millenia. For such skilled programmers it would have 
been obvious in a financial transaction system containing price tables and product 
(component) rules for multiple products (components) and multiple prices and pricing 
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types to develop the computer logic for the many commonly known and used different 
types of pricing methods required for the many products involved and the means for the 
pricing and other calculations required and to employ specific names, identifiers, and 
references for the pricing and product (component) databases (tables) and their data 
fields, together with the programmatic means to both create all of the logic and tables 
and to link them all together for the purpose and function intended to be performed, 
including specifically markup of total price pricing. 

OFFICIAL NOTICE is taken that markup of total price as a pricing method is old 
and well known, and has long been commonly used for goods and services in sales tax 
calculations and in special price calculation circumstances, as one example such as 
whenever the proscribed calculation method became outdated due to a price increase 
not yet there reflected, which required that an additional markup be charged on top of 
the total price, and that it would have been obvious to modify the teachings of Carter 
with this OFFICIAL NOTICE. In view of Gottesmans' teaching, it would have been 
obvious to one skilled in the art at the time of the invention to employ the teachings of 
Gottesman to the teachings of Petroutsos as modified by Carter and OFFICIAL NOTICE 
because the combination of the four would have provided a completed, improved, and 
operational financial transaction system that could have been used by financial service 
companies, complete with a wide variety of pricing types. Likewise, in light of Carter's 
teaching and that of OFFICIAL NOTICE, it would have been obvious to one skilled in 
the art at the time of the invention to integrate the teachings of Carter and OFFICIAL 
NOTICE and Petroutsos with those of Gottesman for the same reason. See responses 
to claims 1 and 6. 

As to Claim 15 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 
10, lines 55-67, and cols 11-13) "The method of Claim 5.... is bundled pricing.", both as 
an inventive concept for pricing as commonly used in financial transactions and as 
means for computer pricing program functions to be performed, but he does not teach 
the many specific variations of pricing , all of which are old and well known, nor the 
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detailed prGgrammatic steps for these software functions. Petroutsos teaches (see his 
book in general, but particularly Chapter 3 at least the sections "Arrays" through "Arrays 
of Arrays", and "lf..Then...End", and Chapter 11 at least the sections "Databases and 
Database Management Systems" through "The Data Contrors Properties"), by example 
of one of several computer programming languages then available, how relatively 
logical, simple, and obvious it would have been for one skilled in the art at the time of 
the invention to create the programming steps necessary to translate an inventive 
concept, like Gottesman's described computer functions to be performed, into a working 
computer software program. Carter teaches (see at least Figure 7) approximately 25 
different types of commonly used pricing types, some of which are only a partial listing 
of the many common pricing types, some of which have been used for the past several 
milenia. For such skilled programmers it would have been obvious in a financial 
transaction system containing price tables and product (component) rules for multiple 
products (components) and multiple prices and pricing types to develop the computer 
logic for the many commonly known and used different types of pricing methods 
required for the many products involved and the means for the pricing and other 
calculations required and to employ specific names, identifiers, and references for the 
pricing and product (component) databases (tables) and their data fields, together with 
the programmatic means to both create all of the logic and tables and to link them all 
together for the purpose and function intended to be performed, including specifically 
bundled pricing. 

OFFICIAL NOTICE is taken that one of the oldest and best known pricing types 
is the bundled pricing type, which has long been commonly used for goods as part of 
the normal pricing method, as one example the sale of new cars, wherein several 
pieces of optional equipment that have been individually priced at full retail were 
routinely included with the car at a discounted value (bundled pricing) when purchased 
all together with the car, and that it would have been obvious to modify the teachings of 
Carter with this OFFICIAL NOTICE. In view of Gottesmans' teaching, it would have 
been obvious to one skilled in the art at the time of the invention to employ the 
teachings of Gottesman to the teachings of Petroutsos as modified by Carter and 
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OFFICIAL NOTICE because the combination of the four would have provided a 
completed, improved, and operational financial transaction system that could have been 
used by financial service companies, complete with a wide variety of pricing types. 
Likewise, in light of Carter's teaching and that of OFFICIAL NOTICE, it would have been 
obvious to one skilled in the art at the time of the invention to integrate the teachings of 
Carter and OFFICIAL NOTICE and Petroutsos with those of Gottesman for the same 
reason. See responses to claims 1 and 6. 

As to Claim 16 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 6, lines 25-67, col 7, lines 48-67, col 
8, col 9, col 10, and cols 1 1-13) "The method of Claim 5. ...is Cross CAA Bundled 
Tiering.", which he describes as Relationship Pricing, both as an inventive concept for 
pricing as commonly used in financial transactions and as means for computer pricing 
program functions to be performed, and although he does teach tiering, he does not 
teach the many specific variations of pricing by name, all of which are old and well 
known, nor the detailed programmatic steps for these software functions. However, it is 
inherent in financial institution pricing to analyze customer accounts, both across their 
several accounts and across the accounts of all major customers, and to employ a wide 
variety of pricing methods to price their services, including bundling and tiering, 
especially in relationship pricing which is essentially bundled pricing by definition. 
Petroutsos teaches (see his book in general, but particularly Chapter 3 at least the 
sections "Arrays" through "Arrays of Arrays", and "If.. .Then. ..End", and Chapter 11 at 
least the sections "Databases and Database Management Systems" through "The Data 
Control's Properties"), by example of one of several computer programming languages 
then available, how relatively logical, simple, and obvious it would have been for one 
skilled in the art at the time of the invention to create the programming steps necessary 
to translate an inventive concept, like Gottesman's described computer functions to be 
performed, into a working computer software program. Carter teaches (see at least 
Figure 7) approximately 25 different types of commonly used pricing types , including 5 
which contain the word "customer", which are only a partial listing of the many common 
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pricing types, some of which have been used for the past several milenia. For such 
skilled programmers it would have been obvious in a financial transaction system 
containing price tables and product (component) rules for multiple products 
(components) and multiple prices and pricing types to develop the computer logic for 
the many commonly known and used different types of pricing methods required for the 
many products involved and the means for the pricing and other calculations required 
and to employ specific names, identifiers, and references for the pricing and product 
(component) databases (tables) and their data fields, together with the programmatic 
means to both create all of the logic and tables and to link them all together for the 
purpose and function intended to be performed, including specifically cross customer 
account analysis (CAA) bundled tiering pricing, which is inherent in and is relationship 
pricing. In view of Gottesmans' teaching, it would have been obvious to one skilled in 
the art at the time of the invention to employ the teachings of Gottesman to the 
teachings of Petroutsos as modified by Carter because the combination of the three 
would have provided a completed, improved, and operational financial transaction 
system that could have been used by financial service companies, complete with a wide 
variety of pricing types. Likewise, in light of Carter's teaching, it would have been 
obvious to one skilled in the art at the time of the invention to integrate the teachings of 
Carter and Petroutsos with those of Gottesman for the same reason. See responses to 
claims 1 and 6. 

As to Claim 21 Gottesman inherently discloses (see at least cols 1-14, but 
particularly col 4, lines 42-67, col 5, lines 1-57, col 7, lines 48-67, col 8, lines 1-16, col 
10, lines 55-67, and cols 11-13) "The method of Claim 1, wherein said price table 
contains costs.", both as an inventive concept for pricing as commonly used in financial 
transactions and as means for computer pricing program functions to be performed, but 
he does not teach the many specific variations of pricing , all of which are old and well 
known, nor the detailed programmatic steps for these software functions. Petroutsos 
teaches (see his book in general, but particularly Chapter 3 at least the sections 
"Arrays" through "Arrays of Arrays", and "If.. .Then. ..End", and Chapter 1 1 at least the 
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sections "Databases and Database Management Systems" through "The Data Control's 
Properties"), by example of one of several computer programming languages then 
available, how relatively logical, simple, and obvious it would have been for one skilled 
in the art at the time of the invention to create the programming steps necessary to 
translate an inventive concept, like Gottesman's described computer functions to be 
performed, into a working computer software program. Carter teaches (see at least 
Figure 7) approximately 25 different types of commonly used pricing types, including 
base cost and one he terms "give it to them for cost", which are only a partial listing of 
the many common pricing types, some of which have been used for the past several 
millenia. The at-cost prices also serve as cost information outside of the cost accounting 
system for any person who wishes to review it. For such skilled programmers it would 
have been obvious in a financial transaction system containing price tables and product 
(component) rules for multiple products (components) and multiple prices and pricing 
types to develop the computer logic for the many commonly known and used different 
types of pricing methods required for the many products involved and the means for the 
pricing and other calculations required and to employ specific names, identifiers, and 
references for the pricing and product (component) databases (tables) and their data 
fields, together with the programmatic means to both create all of the logic and tables 
and to link them all together for the purpose and function intended to be performed, 
including specifically product costs. In view of Gottesmans' teaching, it would have been 
obvious to one skilled in the art at the time of the invention to employ the teachings of 
Gottesman to the teachings of Petroutsos as modified by Carter because the 
combination of the three would have provided a completed, improved, and operational 
financial transaction system that could have been used by financial service companies, 
complete with a wide variety of pricing types. Likewise, in light of Carter's teaching it 
would have been obvious to one skilled in the art at the time of the invention to integrate 
the teachings of Carter and Petroutsos with those of Gottesman for the same reason. 
See responses to claims 1 and 6. 
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6. The prior art of record, although not cited above, is considered pertinent to one 

or nnore of the Applicants* claimed inventions: 

US 4,855,908 to Skimoda et al, which teaches price table lookups. 

US 5,710,887 to Chelliah et al, which teaches pricing rules. 

Boris Beizer, Software Testing Techniques, International Thomson Computer Press, 
Boston, MA, 1990, which teaches the need to test software before implementation. 
Paul Carrubba, Principles of Banking, American Banking Association, 1994, which 
teaches that pricing is based upon account analysis. 



7. Response to Applicant's Arguments 

Claim 1. In the specific reference originally cited, in col 8, on line 2 Gottesman 
states "Transaction pricing...", and refers then to financial services products, which 
makes them " financial transactions " and products, and the logic that applies to the 
product rules, and all the rules, prices, and transactions are linked, stored in a 
database, accessed, identified, and prices are the result, and the broader reference 
cited "(see at least cols 1-14, ...") is the entire patent. Again in the original particular 
reference of col 7, lines 48-67 and col 8, lines 1-16, Gottesman discusses a pricing 
engine that uses pricing rules (logic) in tables, ie: pricing tables, that cover different 
rules, products, prices, and customer types, together with premiums/discounts that may 
apply, different types of financial transactions as specified in the tables, including the 
tier they may include, and the rules include the specific fees that apply to different 
product components to be charged and billed, etc.. The attributes of these pricing rules 
and tables used for financial transactions are the stated products, fees, and customer 
types etc. of Gottesman. Gottesman is not limited to a single account, but to all financial 
transactions of many accounts, some of which may not be termed relationship type 
accounts or transactions, as the relationship premiums/discounts are applied only after 
the standard pricing has already been calculated for each individual type of transaction, 
according to his pricing engine. If the Applicant will reread the particular reference cited 
he will be able to see the many small individual fees that go to make up the larger billino 
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amounts , as Gottesman is not limited to only a larger universe of relationship banking 
prices, Petroutsos simply makes abundantly clear how common and simple it is to 
create computer programs and databases (eg: pricing rules and pricing tables) given 
any specific set of assumptions about them. 

Claim 2. The particular reference in the Claim 1 response includes the attributes 
for and is the billing method and pricing method as described. It is also inherent in any 
elaborate and sophisticated set of pricing rules and tables for it to also translate into and 
contain a billing and pricing method for the charges so calculated. One does not need to 
read the words that something is an " attribute or a method " to make it so, it is simply a 
matter of inherent definition. The Applicant's attention should not be limited to Claim 19 
of Gottesman when his entire patent has been cited as a reference. Applicant has failed 
to provide any evidence that the examiner's original rationale or findings were deficient. 

Claims 3 and 25. Assigning a name to one of many parts of a large set that 
requires subsequent future reference is a practice several millenniums old, and is not 
only obvious but inherent in the design of programs and databases. For the common 
practice as of the applicant's filing date regarding product/pricing rules and tables and 
display-only-information designed into software, it is inherent and obvious in software 
design to include a status field and pricing and billing information and display-only- 
information in order to make the rules and tables operative, and this reasoned argument 
was made in the original rejection. Applicant has failed to provide any evidence that the 
examiner's original rationale or findings were deficient. 

Claims 4 and 5. See response to claims 2, 3, and 25. 

Claims 13 and 15. A reasoned argument was stated in the original rejection for 
the use of obviousness and Official Notice, and the Applicant has not provided any 
credible evidence that the examiner's original rationale or findings were deficient. 
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Claim16. See response immediately above. 
Claims 18 and 28- See response immediately above. 
Claims 19 and 29. See response immediately above. 
Claim 22. See response immediately above. 

Claims 6-16 and 21. As claim 1 remains rejected, Applicant's argument 
becomes mute. For the original reasons stated, each of these claims remain rejected. 

8. Note is taken by the examiner that should the applicant find objectionable any 
statements made herein by the examiner regarding inherency, implicitness, 
obviousness, or Official Notice, Applicant can make a proper challenge to those 
statements only by providing adequate information or argument so that on its face it 
creates a reasonable doubt regarding the circumstances justifying those statements: a 
simple response requesting a reference without doing so, or a response that fails to 
logically refute the basic assumptions underlying the justification, will result in an 
improper and failed challenge and those unchallenged statements will remain the record 
of the case. Applicants must seasonably challenge those statements in the first 
response following an Office Action. If an applicant fails to do so, his right to challenge 
them is waived. 

9. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Richard Fults whose telephone number is 703-305- 
5416. The examiner can normally be reached on Every day 8:30-5:00. If attempts to 
reach the examiner by telephone are unsuccessful, the examiner's supervisor, Vincent 
Millin can be reached on 703-308-1065. The fax phone number for the organization 
where this application or proceeding is assigned is 703-305-7687. 
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Any inquiry of a general nature or relating to the status of this application or proceeding 
should be directed to the receptionist whose telephone number is 703-308-1 113. 
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